<html>


<!-- Mirrored from bos.asmhackers.net/docs/ata/docs/ALLHIW/hiwfnf.HTM by HTTrack Website Copier/3.x [XR&CO'2013], Tue, 07 Oct 2014 11:25:17 GMT -->
<head>
   <title>Hale's HIW: Facts and Fiction</title>
</head>

<body bgcolor="white"> <FONT FACE="Arial">

<H1 ALIGN="center"><FONT COLOR="red">How It Works:
   <br>Facts and Fiction</FONT></H1>

   <p><a href="http://ata-atapi.com/">Go to the ATA-ATAPI.COM Home Page</a></p>

<hr>

<h2><font color="blue">Facts and Fiction</font></h2>

   <ul>
      <li><a href="#T2"><FONT COLOR="green">
          Who Is Hale Landis?</font></a></li>
      <li><a href="#T4"><FONT COLOR="green">
          What is a Mega Anyway?</font></a></li>
      <li><a href="#T6"><FONT COLOR="green">
          Standard(?) I/O Port Addresses and Interrupt Numbers</font></a></li>
      <li><a href="#T8"><FONT COLOR="green">
          Logical Block Addressing (LBA)</font></a></li>
      <li><a href="#T10"><FONT COLOR="green">
          Which is better: LARGE or LBA?</font></a></li>
      <li><a href="#T12"><FONT COLOR="green">
          Even More About LBA</font></a></li>
      <li><a href="#T14"><FONT COLOR="green">
          Low Level Formating</font></a></li>
      <li><a href="#T16"><FONT COLOR="green">
          Zone Bit Recording (ZBR)</font></a></li>
      <li><a href="#T18"><FONT COLOR="green">
          Dual Channel ATA Host Adapters and Data Corruption</font></a></li>
      <li><a href="#T20"><FONT COLOR="green">
          Why Disk Drives Break</font></a></li>
      <li><a href="#T22"><FONT COLOR="green">
          Plug and Play (PnP)</font></a></li>
      <li><a href="#T24"><FONT COLOR="green">
          Thermal Calibration and AV Drives</font></a></li>
   </ul>

<h3><a name="T2"><font color="green">Who Is Hale Landis?</font></a></h3>

   <p>(Ahhh...  A very good question...)</p>

   <p>Hale Landis is an ATA/ATAPI interface consultant.  Hale is
   available to teach classes about these interfaces or help
   design hardware or software for these interfaces.  Hale has
   25+ years experience creating diagnostic test software for
   disk storage subsystems and devices.  He is very active in the
   ATA and ATAPI standards committee efforts and is a member of
   the ANSI NCITS T13 committee.</p>

   <p>Over the years Hale has been very active in getting the
   ATA/ATAPI standards updated and has worked very hard to keep
   this interface simple, fast and cheap.  The world doesn't need
   another SCSI or 1394!</p>

<h3><a name="T4"><font color="green">What is a Mega anyway?</font></a></h3>

   <p>And here is something that Hale really hates...</p>

   <p>Someone once wrote:</p>

   <p>HD manufacturers think 1MB = 1e6 bytes, not 1048576
   bytes.</p>

   <p>And Hale said:</p>

   <p>The HD manufacturers are right:  1MB is 1000000
   bytes&#151;it IS NOT 1048576 bytes!  Mega means 1000000 (just
   like kilo means 1000).</p>

   <p>Is a 1MHz a frequency of 1048576 cycles/second?  NO!  It is
   1000000 cycles/second.  Is a kilometer 1024 meters?  NO!  It
   is 1000 meters.</p>

   <p>Mega, Kilo, etc are ISO defined terms that predate the
   computer industry by many decades!</p>

<h3><a name="T6"><font color="green">Standard(?) I/O Port Addresses and Interrupt Numbers</font></a></h3>

   <p>The following table shows the most commonly supported I/O
   port addresses and IRQ numbers used for PC ATA (IDE/EIDE) host
   adapters.</p>

   <table width="60%" border="1" cellspacing="1" cellpadding="5" align="center">

   <tr>
       <td width="25%" align="center"><b>Interface Number</b></td>
       <td width="25%" align="center"><b>CS0- Decode</b></td>
       <td width="25%" align="center"><b>CS1- Decode</b></td>
       <td width="25%" align="center"><b>IRQ number</b></td>
   </tr>

   <tr>
       <td width="25%" align="center">1</td>
       <td width="25%" align="center">01F0h-01F7h</td>
       <td width="25%" align="center">03F6h-03F7h</td>
       <td width="25%" align="center">14</td>
   </tr>

   <tr>
       <td width="25%" align="center">2</td>
       <td width="25%" align="center">0170h-0177h</td>
       <td width="25%" align="center">0376h-0377h</td>
       <td width="25%" align="center">15</td>
   </tr>

   <tr>
       <td width="25%" align="center">3</td>
       <td width="25%" align="center">01E8h-01EFh</td>
       <td width="25%" align="center">03EEh-03EFh</td>
       <td width="25%" align="center">12 or 11</td>
   </tr>

   <tr>
       <td width="25%" align="center">4</td>
       <td width="25%" align="center">0168h-016Fh</td>
       <td width="25%" align="center">036Eh-036Fh</td>
       <td width="25%" align="center">10 or 9</td>
   </tr>

   </table>

   <p>Now some history and notes...</p>

   <p><b>Interface number 1 -- The Primary</b><br> <br> The
   addresses and IRQ number for the first interface have been
   well established since the first IBM PC/AT system in 1984.
   This is the address and IRQ used by the MFM controller in the
   original IBM PC/AT.  All PC software (BIOS and OS) support the
   primary host adapter (because they support an MFM, RLL or ESDI
   controller using this configuration).  Remember that ATA
   (IDE/EIDE) is designed to operated just like an old MFM
   controller (of course there are new features in ATA that MFM,
   RLL and ESDI did not support).</p>

   <p><b>Interface number 2 -- The Secondary</b><br> <br> During
   1995 support for second interface has become very well
   established.  Some implementations of this interface number
   have used IRQ&#146;s other than 15 in the past.  Today, IRQ 15
   has become the accepted standard for the secondary
   interface.</p>

   <p><b>The other interfaces</b><br> <br> The addresses and
   IRQ&#146;s used by the 3<sup>rd</sup> and 4<sup>th</sup>
   interfaces is not very standard.  Usually it is the ATA (IDE)
   interface on some other type of card, such as a sound card,
   that is used for the 3<sup>rd</sup> or 4<sup>th</sup> ATA host
   adapter in a system.  There is no standardized BIOS or OS
   support for such configurations and usually an OS device
   driver is required to access these ATA host adapter
   addresses.</p>

<h3><a name="T8"><font color="green">Logical Block Addressing (LBA)</font></a></h3>

   <p><b>LBA DOES NOT SOLVE THE &gt;528MB PROBLEM!</b></p>

   <p>There continues to be a large amount of very false
   information floating around in newsgroups concerning LBA
   addressing on ATA (IDE) drives.</p>

   <p>Please, lets get this correct...</p>

   <ul>
      <li>LBA has NOTHING to do with fixing the &gt;528MB problem. </li>
      <li>LBA does NOT solve the &gt;528MB problem. </li>
      <li>It is not true that LBA is needed to support a drive &gt;528MB. </li>
   </ul>

   <p>An INT 13H BIOS that does CHS translation is the ONLY way
   to support a drive &gt;528MB today.  CHS translation enables
   the use of &gt;16 heads with &lt;=1024 cylinders at the INT
   13H interface while using &lt;=16 heads and &gt;1024 cylinders
   (or maybe LBA) at the drive interface.</p>

   <p>FDISK uses CHS.  It does not use LBA.  It does not know (or
   care) if LBA is being used at the device interface.  FDISK can
   not address any part of a disk that can not be accessed in CHS
   mode.</p>

   <p>Microsoft operating systems WILL NOT use any part of a disk
   that can not be accessed in CHS mode.  Read the Microsoft
   documentation carefully.  OS/2 and Linux do have a special
   FDISK &quot;hack&quot; that allows partitions to span or be
   beyond the 528MB boundary even on systems that don&#146;t have
   a CHS translating BIOS and even on drives that don&#146;t
   support LBA.  Be very careful when using this feature of OS/2
   or Linux.</p>

   <p>LBA provides only a slight performance improvement for some
   protected mode operating systems, HOWEVER, those systems MUST
   still boot in CHS mode and use CHS mode to understand the
   drive configuration data returned by INT 13H AH=08H and to
   understand the partition layout of the drive.  If an OS
   decides to use LBA addressing it MUST not attempt to access
   any sectors that are beyond those that can be accessed by the
   CHS mode returned by INT 13H AH=08H.  Therefore, the size of a
   drive in LBA mode is the same as the size in CHS mode.  If the
   INT 13H BIOS does not support drives &gt;528MB then LBA mode
   can not be used make the drive look &gt;528MB either.</p>

   <p>So, once again, LBA does not solve the &gt;528MB problem.
   Don&#146;t be confused by the the BIOS vendors that claim LBA
   solves the &gt;528MB problem.  They are confusing you by using
   LBA to explain that their BIOS is really doing CHS
   translation.  It is very unfortunate that they are using LBA
   so incorrectly.  We can probably thank Western Digital&#146;s
   EIDE Implementation Guide for starting this confusion.</p>

   <p>NOTE:  If you are about to send me email to tell me how
   wrong I am, please see my &quot;How It Works&quot; series of
   documents that describe how the MBR and boot sectors work, or,
   disassemble the master boot record on your system and look at
   how your system boots.  You will find that it does not use LBA
   at all.  If after doing this you still think I&#146;m wrong,
   then send me email.  Thanks!</p>

<h3><a name="T10"><font color="green">Which is better: LARGE or LBA?</font></a></h3>

   <p>Hmmm...  The truth is this:  The LBA option is not stable
   and is not the &quot;standard&quot; that will survive in the
   future.  I&#146;ve posted several articles in the past about
   this but the misleading information comes faster than I and
   others can keep up.</p>

   <p>The truth is that the IBM/MS/Phoenix extended/enhanced BIOS
   specification <b>is</b> the future &quot;standard&quot; and it
   is being widely implemented.  This &quot;standard&quot; does
   not require the use of LBA at the drive interface.  Using LBA
   at the device interface never did and never will solve the
   &gt;528MB (&gt;1024 cylinder) problem.  Only CHS translation
   at the INT 13 interface or LBA at the INT 13 interface solves
   this problem.</p>

   <p>The truth is that the LBA BIOS option is a poorly designed
   and very poorly documented Western Digital idea that should
   have never been adopted by the PC industry.  Even WD
   doesn&#146;t actively support it any more.</p>

   <p>Maybe this table will help everyone understand this
   problem...  </p>

   <table width="90%" border="1" cellspacing="1" cellpadding="5" align="center">

   <tr>
       <td width="30%"><b>drive size</b></td>
       <td width="30%"><b>INT 13 interface </b></td>
       <td width="40%"><b>IDE/EIDE drive interface</b></td>
   </tr>

   <tr>
       <td width="30%">&lt;528MB and &lt;1024 cyl</td>
       <td width="30%">any old BIOS works -- no CHS translation is required.</td>
       <td width="40%">CHS used here is the same as the CHS used at the INT 13 interface.</td>
   </tr>

   <tr>
       <td width="30%">&gt;528MB or &gt;1024 cyl but less than 8GB</td>
       <td width="30%">CHS translation required -- keep cylinders under 1024 and use more than 16 heads
          <p>implementation #1 is described by IBM/MS/Phoenix documents.</p>
          <p>implementation #2 is described by the WD EIDE guide.</p></td>
       <td width="40%">two possible implementations exist:
          <p>#1 the &quot;standard&quot; or LARGE
          implementation uses CHS at the drive interface and
          generally gives better performance. </p>
          <p>#2 the WD EIDE BIOS or LBA
          implementation uses LBA at the drive interface (for no
          good reason). This is not the &quot;standard&quot; of the
          future and it can confuse some OS device drivers -- this
          is why so many versions of the Windows FastDisk (32-bit
          disk access) driver exist today. This BIOS implementation
          does not work for drives of 8GB or bigger.</p></td>
   </tr>

   <tr>
       <td width="30%">8GB or bigger</td>
       <td width="30%">IBM/MS/Phoenix
          &quot;standard&quot; is the only thing that works. LBA is
          used at the INT 13 interface!</td>
       <td width="40%">either
          CHS or LBA can be used at the device interface.</td>
   </tr>

   </table>

   <p><b>Note:</b> The IBM/MS/Phoenix &quot;standard&quot; works
   for all drive sizes including drives with up to 2^64 sectors
   (really big drives!).  The WD LBA BIOS implemetation fails
   when drives get to 8GB and it also doesn&#146;t include any of
   the Plug-and-Play stuff that future operating systems will
   require.</p>

   <p>I really think that someone at WD got confused about how
   LBA should be used.  It appears to me that this WD person (or
   persons) thought that using LBA at the device interface would
   solve the big disk problem.  What they overlooked was this:
   LBA at the INT 13 interface is what really solves the big disk
   problems.  LBA at the device interface isn&#146;t needed to
   solve any big disk problem (even for 100GB drives)!</p>

   <p>As I&#146;ve said before, those of you that are using the
   LBA option in your BIOS setup <b>may</b> find that some day
   you&#146;ll have to back up all your data and switch to the
   LARGE option in order to remain compatible with the real BIOS
   &quot;standard&quot;.</p>

<h3><a name="T12"><font color="green">Even More About LBA</font></a></h3>

   <p><b>What does LBA do for me?</b><p>

   <p>Some people in this message thread seem to be confused here
   about the use of LBA to:</p>

   <ol>
       <li>get around the 528MB problem,</li>
       <li>reformatting the disk because of LBA,</li>
       <li>performance increase due to LBA.</li>
   </ol>

   <p>I&#146;m not sure were all this started but, lets take a
   brief look at each of these...  </p>

   <ol>
      <li>LBA does not solve the &gt;528MB problem. Only a BIOS
        with an INT 13 that does CHS translation solves this
        problem. How the BIOS sends sector addresses to the disk
        drive, as CHS or as LBA, should not change the CHS that
        is used at the INT 13 interface.<br>
        <br>
        Yes, there is at least one BIOS type out there that has a
        problem with this: any BIOS based on the Western Digital
        EIDE Implementation Guide may change the CHS used at the
        INT 13 interface when the use of LBA at the device
        interface is turned on or off. This is a very flawed
        implementation and should be avoided OR if you have such
        a BIOS, NOT do change the LBA setting in the CMOS setup
        once you have partitioned your disk and installed your
        software.</li>
      <li>As long as the CHS at the INT 13 interface does not
        change, it should make not difference if CHS or LBA is
        being used at the drive&#146;s interface. CHS and LBA are
        completely interchangeable at the drive interface on a
        command by command basis.<br>
        <br>
        However, beware of these WD EIDE BIOS types. These BIOS
        incorrectly change the CHS used at the INT 13 interface
        when LBA use at the drive interface is changed. This
        should not be. This is the major flaw in the WD EIDE BIOS
        type. It represents a serious threat to your data!</li>
      <li>LBA use will not give any great performance increase. In
        fact, on some drives it may decrease performance. The
        disk drive industry has had many years to optimize the
        use of CHS at the drive&#146;s interface. Many drives do
        NOT convert the CHS at the interface to an LBA
        internally. In these drives, using LBA at the
        drive&#146;s interface just causes the drive more
        overhead as it must convert the LBA to a CHS before it
        can proceed with the command.</li>
   </ol>

   <p><b>Is LBA slower?</b><p>

   <p>Someone once posted this on UseNet:</p>

   <p>&gt;..., no it is not slower, just a different geometry
   translation, &gt;and at the same speed as long as the system
   supports LBA, &gt;and is set up correctly.</p>

   <p>Beware...  LBA <b>can</b> be slower for two reasons:</p>

   <ol>
      <li>Conversion of INT 13 CHS input to an LBA at the device
        interface (when LBA is used in BIOS setup) usually
        requires more instructions than conversion of INT 13 CHS
        input to another CHS at the device interface (when CHS
        translation is used in BIOS setup, aka LARGE).</li>
      <li>LBA processing in many drives is slower than CHS
        processing (this will change as drive vendors optimize
        their hardware and firmware for LBA in future drives).
        Many people can measure a slight difference in
        performance between CHS and LBA today. </li>
   </ol>


<h3><a name="T14"><font color="green">Low Level Formating</font></a></h3>

   <p><b>What does low-level format do on an ATA
   (IDE) drive?</b></p>

   <p><b>Answer:</b> Depends on how old the ATA drive is and who
   made it.</p>

   <p>Lets talk about what low-level formatting is...</p>

   <p>In the old days of MFM, RLL and ESDI, a new hard disk drive
   was just like a new unformatted floppy&#151;there was nothing
   on it.  The drive had to be connected to a controller and the
   controller had to be told how many sectors per track to lay
   down on each track&#151;this is the same thing you do when you
   format a floppy these days.  Formatting of each track creates
   the inter sector gaps, the sector ID fields and the sector
   data fields.  Most MFM/RLL/ESDI controllers include a small
   low-level formatting program in ROM.  You generally use DOS
   DEBUG to enter this program.</p>

   <p>Lets talk about what high-level formatting is...</p>

   <p>High level formatting creates a file system within a
   partition of a hard disk or on a floppy.  This process writes
   the initial version of the boot record, root directory and
   file allocation table (FAT).</p>

   <p>Here is a bit of confusion&#151;when you use the DOS FORMAT
   command to format a floppy, you are doing BOTH a low-level and
   high level format at the same time.  When you use the DOS
   FDISK and FORMAT commands to format a hard disk, all you are
   doing is the high level format.</p>

   <p>Back to hard disks...</p>

   <p>MFM/RLL/ESDI and some older ATA drives use the same
   controller command code, known as Format Track, to do the
   low-level format of a track.  This command is issued once for
   each track on the hard disk.  This command writes the inter
   sector gaps, the sector ID fields and the sector data fields.
   Each sector on a track has an ID&#151;an 8-bit binary number
   usually starting at 1. The order is which the sector IDs are
   written determines the interleave.  If the sector IDs are
   written as 1, 2, 3, ..., n, this is 1-to-1 interleave.  When
   written as 1, n, 2, n+1, 3, ..., n-1, you have 2-to-1
   interleave.  MFM controllers usually used 2-to-1 or 3-to-1
   interleave with 17 sectors per track.  RLL usually used 26
   sectors per track.</p>

   <p>MFM/RLL/ESDI also would allow &quot;marking&quot; a sector
   &quot;bad&quot; as the sector ID field was being created.
   This would cause a very special kind of error on any read or
   write command that attempted to access this sector&#151;a Bad
   Block error.  When you run the DOS FORMAT program, it reads
   every sector in the partition looking for &quot;bad&quot;
   sectors and sectors with uncorrectable data errors.  Such
   sectors then cause clusters of sectors in the FAT to be marked
   bad and DOS will never use them.  Other systems, such as OS/2
   HPFS, Unix, etc, keep bad block lists as part of their file
   system data and they also do not access these &quot;bad&quot;
   sectors.</p>

   <p>MFM/RLL/ESDI drive technology was generally based on using
   a stepper motor to position the read/write heads.  Over time
   the bearings in the drive would wear and read/write errors
   would appear because the stepper motor was no longer
   positioning the read/write heads in the right place.  The
   solution was to do a low-level format again.</p>

   <p>New drives don&#146;t use stepper motors and instead use
   embedded servo bursts in between the sectors.  These burst are
   used to locate tracks and sectors and to keep the read/write
   heads properly positioned even when the drive&#146;s bearing
   are worn.  More important is keeping the read/write heads
   properly positioned under a wide range of temperatures.
   Thermal expansion can change the length of the arm the
   read/write head is attached to by as much as 5 or 10 tracks!
   This is the reason you hear new drives doing a lot of thermal
   calibration (that strange seeking noise you hear when there
   should be no disk activity).</p>

   <p>The servo bursts are written at the factory in a very
   controlled environment using some very expensive equipment.
   The drive alone can not recreate these servo data bursts.
   Likewise, because most drives are now zone recorded (they have
   different number of sectors per track at different locations
   on the media), the inter sector gaps, sector ID fields and
   sector data fields are also written at the factory and can not
   be recreated later.  Some drives may soon do away with the
   sector ID fields and some of the gaps in order to increase
   data storage capacity.</p>

   <p>Now for the history the ATA Format Track command...</p>

   <p>Early ATA drives did not really implement the Format Track
   command&#151;it was thought to be obsolete (and it was).  What
   was implemented was a simple writing of some data pattern into
   each sector of each track formatted.  Most drives did not
   support marking sectors bad.  However, the disk drive industry
   is driven by features and slowly, one-by-one, the hard disk
   vendors started implementing the command such that it did the
   same thing as in MFM/RLL/ESDI.  Then someone implemented the
   ability to &quot;reassign&quot; a sector&#146;s address to a
   different physical sector on the disk.  Never mind that there
   were <b>no</b> programs then and few now that use the Format
   Track command to do this.</p>

   <p>The original ATA specification (now at rev 4.0c, also known
   as ATA-1) documents the &quot;full&quot; function Format Track
   command but leaves it to the drive vendor to decide what a
   drive will really do.  It recommends a minimum action of
   writing binary zero into the data field of each sector
   formatted.  The ATA-2 specification says that the function of
   the command is &quot;vendor specific&quot;&#151;it
   doesn&#146;t even recommend the minimum action of writing
   binary zero data&#151;a major step towards (finally) making
   the command obsolete.  </p>


   <p><b>So what does low-level formatting do on a modern ATA drive?</b></p>

   <p>Assuming that you can find a program that really does issue
   the ATA Format Track command your ATA drive probably
   doesn&#146;t do anything other than write some data pattern,
   maybe binary zeroes, into the data field of every sector on
   the drive.  That is no different than just using the normal
   write command and writing data into every sector on the drive.
   In general, low-level formatting of an ATA drive is just a big
   waste of time.</p>

   <p>So several things have gotten us to this time and
   place:</p>

   <ol>
      <li>No stepper motors.</li>
      <li>Very close track spacing.</li>
      <li>Embedded servo data.</li>
      <li>Zone recording.</li>
      <li>Few programs that use the Format Track command.</li>
      <li>The Format Track command DOUBLES the amount of
          firmware in a drive.</li>
      <li>And then there is the failure rate problem... There
          are two major components in a disk drive&#151;the
          Head/Disk Assembly (HDA, contains the media and
          read/write heads) and the printed circuit board with
          the electronics&#151;which fails most frequently?</li>
    </ol>

   <p><b>THE ELECTRONICS!</b></p>

   <p><b>Wait a minute...</b> Are you trying to say the
   electonics are more unreliable than the HDA (media and
   heads)?</p>

   <p>In general the failure rate for the electronics is slightly
   higher than the failure rate of the media and heads.  High
   temperatures and heating/cooling cycles cause failure of the
   little gold wires inside the chips.  This could be a good
   reason to make sure your drive has adequate cooling and leave
   it on most of the time.  But heat is the big problem
   here&#151;it is just a matter of time before the HDA or the
   electronic will fail.  Of course rough handling (like dropping
   the drive) will probably not damage the electronics but will
   damage heads or media.</p>

<h3><a name="T16"><font color="green">Zone Bit Recording (ZBR)</font></a></h3>

   <p>ZBR maintains a constant data bit density across the disk
   surface.  This done by placing more sectors on tracks at the
   outside of the disk and fewer sectors at the inside edge of
   the disk.  Typically, drives have &gt;60 sectors on the
   outside tracks and &lt;40 on the inside tracks.  This does
   cause the disk&#146;s raw data rate to change.  The data rate
   is higher on the outside than on the inside.  Most ZBR drives
   have at least three zones.  Some my have 30 or more.  All of
   the tracks within a zone have the same number of sectors per
   track.</p>

   <p>ZBR and embedded servo data are the two major reasons you
   can&#146;t low level format drives anymore.</p>

<h3><a name="T18"><font color="green">Dual Channel ATA Host Adapters and Data Corruption</font></a></h3>

   <p><b>WARNING!  POSSIBLE SYSTEM HANGS AND DATA CORRUPTION
   PROBLEMS!</b></p>

   <p>If you have a dual channel ATA (IDE) host adapter (or you
   are thinking of buying one) either an add in card or on a new
   motherboard, read this.</p>

   <p>First, ATA is the real name for IDE or EIDE.</p>

   <p>Second, dual channel ATA host adapters are two ATA host
   adapters in one package.  These are add in cards with two ATA
   connectors or a motherboard with two ATA connectors.  You can
   attach up to two ATA devices per host adapter (up to two
   devices per cable).</p>

   <p>Normally one host adapter will be assigned to the
   &quot;primary&quot; I/O addresses (1F0-1F7H and 3F6H) and the
   other host adapter will be assigned to the
   &quot;secondary&quot; I/O addresses (1790177H and 376H).</p>

   <p>A single ATA host adapter looks like this internally:</p>

   <pre><font face="Courier New">
                         ATA interface
                               |
   host                        |
   bus                         V

   ||       +---------+  control      +----------+    +----------+
   ||       |         |  signals      |          |    |          |
   ||       |         |<------------->|          |<-->|          |
   ||       | host    |               |  drive   |    |  drive   |
   ||<=====>| adapter |  16-bit       |    0     |    |    1     |
   ||       | logic   |  data bus     | (master) |    | (slave)  |
   ||       |         |<------------->|          |<-->|          |
   ||       |         |               |          |    |          |
   ||       +---------+               +----------+    +----------+
   </font>
   </pre>

   <p>A dual channel host adapter should have two complete ATA
   host adapters with no shared logic, no shared signals, no
   shared functions of any kind.</p>

   <p>According to some estimates, up to 30 percent of all dual
   channel host adapters now on the market (as boards or as on
   motherboard designs) have a serious flaw.  This flaw can
   result in data corruption.  The flaw is that these dual
   channel host adapters &quot;share&quot; the data bus between
   the two ATA cables.  This results in a host adapter that looks
   like this internally:</p>

   <pre><font face="Courier New">
                       ATA interfaces
                             |
   host                      |
   bus                       V

   ||    +-----------+  control    +----------+    +----------+
   ||    |           |  signals    |          |    |          |
   ||    | primary   |<----------->|          |<-->|          |
   ||    | host      |             |  drive   |    |  drive   |
   ||    | adapter   |             |    0     |    |    1     |
   ||    | logic     |             | (master) |    | (slave)  |
   ||    |           |   +-------->|          |<-->|          |
   ||    | shared    |   |         |          |    |          |
   ||    | data      |   | 16-bit  +----------+    +----------+
   ||<==>| bus       |<--+ data
   ||    | logic     |   | bus     +----------+    +----------+
   ||    |           |   |         |          |    |          |
   ||    |           |   +-------->|          |<-->|          |
   ||    | secondary |             |  drive   |    |  drive   |
   ||    | host      |  control    |    0     |    |    1     |
   ||    | adapter   |  signals    | (master) |    | (slave)  |
   ||    | logic     |<----------->|          |<-->|          |
   ||    |           |             |          |    |          |
   ||    +-----------+             +----------+    +----------+
   </font>
   </pre>

   <p>Data corruption can come from two sources in this
   design:</p>

   <ol>
      <li>the minor reason is that the data bus exceeds the ATA 18
        inch maximum length. This design makes the two cables
        look like one 36 inch cable.</li>
      <li>the major reason is that a multitasking operating system
        expects to be able to perform an I/O operation at the
        same time on both the primary and secondary host
        adapters. This design will corrupt data (or cause hang
        conditions) because of the shared data bus. </li>
   </ol>


   <p><b>How can you identify a flawed dual channel host adapter?</b></p>

   <p>One way is to look at the printed circuit board and count
   the number of direct connections between the pins of the
   primary host adapter connector and secondary host adapter
   connector.  This may be difficult on multilayer printed
   circuit boards.  It is normal for a few signals (such as
   ground signals) to be tied together directly.  However, if you
   see a large number of pins (more than 16) tied directly
   together by copper traces on the circuit board, you are
   looking at one of these flawed host adapters.</p>

   <p>For example:</p>

   <pre><font face="Courier New">
                primary           secondary
                connection        connector
                pins              pins

                o   o             o   o     pins
                     \_______________/ \___ tied
   pins         o   o             o   o     together
   not      _____________________/
   tied         o   o             o   o
   together ___/
                 ...               ...

                o   o             o   o
   </font>
   </pre>

   <p>However, beware, this visual check is not foolproof!  Pins
   that don&#146;t appear to be tied together in the area of the
   connectors could be tied together at some other location.</p>

   <p>My advice:  Talk to the host adapter (or motherboard)
   technical support people and ask them if the two host adapters
   share any signals, logic or functions.  Any sharing of data
   bus signals, host adapter logic or functions (especially data
   transfer logic) would indicated a flawed design that could
   corrupt your data.</p>

   <p><b>BUYER BEWARE!</b></p>

   <p>If you run Linux, check the latest Linux IDE driver
   information for a version of the IDE driver that will
   serialize all I/O to the two host adapters in order to prevent
   strange things.</p>

   <p>It is unclear at this time (May95) how WinNT, Win95 or OS/2
   will deal with these host adapters.</p>

   <p><b>BEWARE OF INTEL TRITON DUAL CHANNEL HOST ADAPTERS</b></p>

   <p>The Triton is even worse than first look gave.  True, it
   does not corrupt data or do strange things with interrupts,
   but it can have what I consider to be serious performance
   problems.  Now that Intel has made the chip spec public, we
   can all find out that not only does the chip share the two ATA
   data buses but that combined bus is also shared with the ISA
   address/data bus function that is also in the chip.  Intel
   claims &quot;fair round robin&quot; sharing of all the uses of
   the single bus.  So if you have your serial or parallel ports
   on the Triton ISA bus and you have any COM or LPT activity
   going on this will be multiplexed with your two ATA interfaces
   on the same set of signals comming out of the Triton chip.  So
   much for high performance.</p>

<h3><a name="T20"><font color="green">Why Disk Drives Break</font></a></h3>

   <p><b>Why do hard drives fail?</b></p>

   <p>There are three major (and these really are the only three
   real reasons hard disk drives fail):</p>

   <ol>
      <li>they get to hot (your system cooling fan quits working).</li>
      <li>they are mishandled (dropped or banged around).<br>
        <br>
        Drives that have been over heated or mishandled can
        develop bad sectors as time goes on. Usually you will see
        one bad sector and then a few more and then a bunch more
        until the drive is basicly not worth using any more.<br>
        <br>
        A drive that really gets too hot may refuse to spin up
        because the heads get &quot;glued&quot; to the media by
        the high heat.</li>
      <li>an electronics failure.<br>
        <br>
        Electronics failures are usually sudden and without
        warning. A common time for a drive&#146;s electronics to
        fail are on Monday morning after the drive has been
        powered off all weekend. It is the heating/cooling cycles
        that cause breaks in the printed circuit board or breaks
        in the little gold wires inside the chips on the printed
        circuit board.<br>
        <br>
        You can also zap the electronics by handling a drive when
        you are not properly grounded.</li>
   </ol>

   <p><b>What can I do?</b></p>

   <p>Make that your drive is properly cooled, don&#146;t drop it
   and be grounded before you touch a drive!</p>

   <p>OK, every once in awhile a disk vendor will make a bunch of
   drives that have some kind of dirt or chemical inside that
   should not be there.  Drives with this kind of problem usually
   don&#146;t last very long and usually fail during the warranty
   period.  This is a very rare thing to have happen these days
   but the failure mode is usually the same as described above
   for over heating.</p>

<h3><a name="T22"><font color="green">Plug and Play (PnP)</font></a></h3>

   <p>As many people have found out PnP is a joke.  It is a cute
   marketing thing to make you think that the computer hardware
   and software vendors have solved all the hardware and software
   configuration problems for you.  Just plug in a new device and
   the system will recognize it and allow you to use it.  Ha
   Ha!</p>

   <p>What is PnP really?  It is a bunch of uncoordinated and
   proprietary solutions to specific hardware or software
   configuration problems.  Many of the so called PnP
   specifications were developed by individual companies or
   groups of companies (aka, private clubs) to enhanced their
   image with the computer buying public.  Most of these
   specifications are short sighted and don&#146;t address all of
   the issues.</p>

   <p>There are so many PnP specifications floating around the
   industry that no one has a complete list of them.  New ones
   appear monthly.  It is a major mess.</p>

   <p>A specific example is the PnP mess related to ATA
   (IDE/EIDE) devices.  Several years ago various hardware
   specificaion groups (VESA and PCI and others) attempted to
   defined PnP for various type of host adapters, including ATA
   (IDE/EIDE) host adapters.  But these groups addressed only the
   hardware aspects of the host adapter configuration.  They
   forgot to address the BIOS issues!</p>

   <p>So the PnP mess continues on and grows bigger each day.</p>

<h3><a name="T24"><font color="green">Thermal Calibration and AV Drives</font></a></h3>

   <p>Someone once posted this on UseNet:</p>

   <p>&gt;The way I see it, there are (at least) two common <br>
   &gt;myths floating around about SCSI and EIDE drives.</p>

   <p><b>Myth #1:  SCSI has better sustained throughput than
   EIDE.</b></p>

   <p>&gt;As I understand it, the SCSI 3 bus is capable of higher
   <br> &gt;bandwidth than EIDE on a PCI bus, but that is
   irrelevent,<br> &gt;because the hard drives themselves
   don&#146;t come anywhere <br> &gt;near using the available
   bandwidth.  As far as I can tell,<br> &gt;the high end of SCSI
   drives (single drives, anyway) are <br> &gt;capable of approx
   7 MB/sec sustained throughput.  And<br> &gt;the high-end EIDE
   drives (PIO Mode 4) are capable of <br> &gt;about the same
   sustained throughput.  True or false?</p>

   <p>Nearly always FALSE (due to IDE/EIDE&#146;s extremely low
   command overhead) except that there are real high capacity and
   real high performance drives that come only with the SCSI
   interface.  This will probably change in the future.</p>

   <p>Plus there is the old question of &quot;how many reads are
   from the drive&#146;s cache?&quot;.  A cache read is just a
   memory (in the drive) to memory (in the system) transfer and
   can, in theory, be done at extremely high speeds (much faster
   than the drive&#146;s actually media tranfer rate).</p>

   <p>Today, for the same transfer rate, EIDE is cheaper
   (especially when you include the cost of host adapters and
   cables).</p>

   <p>Who knows what tomorrow will bring.  There are many people
   in the disk drive industry working on faster EIDE and faster
   SCSI data transfer protocols.  And they probably are also
   working on the interface that will replace both EIDE and SCSI
   (for disk drives).  Neither EIDE or SCSI can keep up with the
   disk technology that is just over the hill now and moving
   towards us very rapidly.  Expect an entirely new hard disk
   interface in a few years as drives approach data transfer
   rates of 100+MB/second.</p>

   <p><b>Myth #2:  Only drives sold as &quot;AV&quot; drives are
   capable of uninterrupted sustained throughput.</b></p>

   <p>This is based on a problem which no longer exists.
   <br> &gt;Older drives used to pause every so often to
   recalibrate <br> &gt;their head positions, the so-called
   &quot;thermal recal&quot;.  <br> &gt;As I understand it, just
   about all drives now use <br> &gt;a system of so-called servo
   tracks which are written <br> &gt;onto the platter surfaces.
   Thus, as the drives get <br> &gt;hotter and the material
   expands, the servo tracks <br> &gt;expand right along with
   them, and so there&#146;s no need <br> &gt;for thermal recal
   anymore.  True or false?</p>

   <p>Well, sort of TRUE and sort of FALSE.  ALL drives MUST do
   thermal calibration every so often.</p>

   <p>Until a few years ago most drives had &quot;dedicated
   servo&quot; systems (all servo data on one surface and only
   read by one head) that required frequent calibration
   especially if the drives internal temperature was changing
   rapidly (like right after power on).  The so called AV
   versions of this type of drive attempted to reduce the chance
   that the host would notice this drive activity.  This activity
   can distrub the smooth flow of video or sound data during disk
   read/write commands.</p>

   <p>Today most all drives use an &quot;embedded servo&quot;
   system (servo data mixed in with user data on every data
   track, every head reads servo data while reading user data).
   While thermal calibration is still required, its impact on the
   smooth flow of data can be kept to an absolute mimimum.  My
   guess is that some disk vendors will still use the AV label
   just because it&#146;s a good marketing tool.  You may even
   see an AV label on an EIDE drive.</p>

   <p>However, there is another side of this AV thing that you
   didn&#146;t bring up (myth#3?):  reduced error recovery.</p>

   <p>A true AV drive will implement a set of reduced error
   recovery read commands based on the theory that your eye will
   notice a pause in the flow of the video data while the drive
   attempts its normal full error recovery (the picture will
   &quot;pause&quot; or &quot;jump&quot;) but your eye will
   probably ignore a few bad bits of video data flashing across
   the screen (video snow).  On course you don&#146;t want your
   OS to use this reduced error recovery read command when it is
   reading real data (like a directory or you current tax
   return&#146;s data!).</p>

   <p>The bottom line 99% of the time:  Unless you are buying a
   drive that will become part of the disk array that is used to
   store video data, you probably don&#146;t need an AV drive.
   AV drives are really built for this application.</p>

<hr>

   <p><i>This page was last updated on 05 October 1999.</i></p>

</body>

<!-- Mirrored from bos.asmhackers.net/docs/ata/docs/ALLHIW/hiwfnf.HTM by HTTrack Website Copier/3.x [XR&CO'2013], Tue, 07 Oct 2014 11:25:17 GMT -->
</html>
